cc @Jefffrey @comphead — a follow-up to my recently merged hypot PR, this adds a Spark-compatible atan2 function to datafusion-spark.

It follows the existing math conventions — exact(Float64, Float64) -> Float64, invoke via make_scalar_function, reimplemented self-contained (matching the 14/15 math functions that reimplement rather than delegate to core). Backed by Rust's f64::atan2.

Covered by sqllogictest cases: all four quadrants, both axes, the negative x-axis (range to π), NULL propagation, NaN in every position (incl. atan2(NaN, Infinity) = NaN — note NaN propagates even over Infinity here, unlike hypot), all four infinity quadrants, signed zeros, and the array path. Closes #23961.

Would appreciate a review when you have a moment. Thanks!

Codecov Report

❌ Patch coverage is 84.37500% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.70%. Comparing base (74eebbb) to head (5419c96).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main   #23962      +/-   ##
==========================================
- Coverage   80.70%   80.70%   -0.01%     
==========================================
  Files        1095     1096       +1     
  Lines      372554   372586      +32     
  Branches   372554   372586      +32     
==========================================
+ Hits       300661   300683      +22     
- Misses      53924    53929       +5     
- Partials    17969    17974       +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

how is this different from the datafusion functions ver?

how is this different from the datafusion functions ver? @Jefffrey

Good question. The element-wise math is the same underlying f64::atan2, but the return type differs:

• Core atan2 returns Float32 when both inputs are Float32 (single-precision path), Float64 otherwise — this is asserted in core's own tests (scalar.slt): atan2(Float32, Float32) → Float32, every other combination → Float64.
• This Spark version is exact(Float64, Float64) -> Float64: atan2(Float32, Float32) coerces to Float64 and returns Float64, matching Spark, where atan2 is defined over double and always returns double.

So atan2(float_col, float_col) gives Float32 in core but Float64 here — Spark-compatible.

I think this is the same reason abs/ceil/floor/round/rint are reimplemented in datafusion-spark rather than delegating to core: the crate enforces Spark's type semantics (double-only, no Float32-specific path), following the guideline of only accepting Spark-supported types.

Happy to adjust if you'd prefer a different approach here or think otherwise.